This note describes differences between XTND 1.3.6 and the version described in the XTND Programmer’s Guide (1.3). It also provides additional information that was not included in the Guide.
• The XTND Programmer’s Guide does not mention the fact that the XTND Interface Library contains global variables embedded in its code. This means that this code cannot be purged or moved between the time the XTNDInitTranslators call is given and the time the XTNDCloseTranslators call is given. Therefore, the library code should be placed in a segment that will not be moved or purged between the XTNDInitTranslators call and the XTNDCloseTranslators call.
• The XTND Programmer’s Guide also does not describe the XTNDLoadTranslator and the XTNDReleaseTranslator routines—these descriptions were inadvertently omitted. The following two paragraphs describe what these routines are used for:
The load routine, XTNDLoadTranslator, opens a translator file, loads the code resource into memory, and locks it. This routine is called after a translator has been selected, usually with XTNDGetFile or XTNDPutFile, although XTNDMatchFile could be used or the application could select a translator on its own. XTNDLoadTranslator returns a pointer to the code in memory if it succeeded in loading the code resource.
The release routine, XTNDReleaseTranslator, releases the translator code resource and closes the resource file. XTNDReleaseTranslator is intended to be used in conjunction with XTNDLoadTranslator.
(Note that the C and Pascal headers and interfaces contain the correct prototypes for these routines.)
• The directive field in the ExportParmBlock has been changed from an enum to a char so that checking the “enums are always ints” option in THINK C 5.x will not prevent your application from calling XTND translators. In earlier versions of THINK C, enums with values less than 128 were one byte in length, and this is what the current translators are expecting. This change will ensure that the directive field remains a single byte in length regardless of the compiler setting you are using. This change requires no application or translator programming changes.
• The XTND System now includes an additional resource which is used to determine that the proper version of the system is installed. It is called automatically when initializing the engine, so your application need only check an error return from the XTNDInitTranslators routine.
• There is an additional parameter in the SFParamBlock record (see XTNDInterface.h or XTNDInterface.p). It is a FileFilterProcPtr, provided for symmetry when calling SFPGetFile from the XTNDGetFile call. The use of this parameter is documented in Inside Macintosh I-526 and Macintosh Technical Note 47. Your function will return FALSE if the selected file is to appear, and TRUE if it should not appear in the dialog. Remember to set this field to NIL if you do not wish to supply your own filter proc.
• The XTND System has been modified to detect when the XTND Translator List file has been created by a previous version of the XTND System, and to update the file, so it should not be necessary to have the user delete the existing XTND Translator List file when installing the new XTND System file. It is still possible for the file to become corrupted, however, so it may still be necessary to delete the file under some circumstances, but this should be a rare occurrence.
• The sample applications have been modified to fix some bugs. There were also name changes to variables which removed the “Clarisity” of their origin.
• The MacPaint translator included in the Claris Translators folder is now the same as the one built from the example source.
• Finally, the glue code has been renamed so that the files have appropriately matching names.
